The invention relates to arranging a session between a synchronization server and a client device and particularly to starting a session on the initiative of a synchronization server.
Data of portable terminals, such as mobile phones, can be synchronized with network applications, desktop computer applications or other databases of the telecommunication system. In particular, data of calendar and e-mail applications are typically synchronized. Previously, synchronization has been based on the use of different manufacturer-specific protocols which are incompatible. This limits the use of terminals or data types to be used and often causes difficulty to the user. In mobile communication, in particular, it is important that data can be retrieved and updated regardless of the terminal and application used. To improve synchronization of application data, a SyncML (Synchronization Markup Language), which is based on the XML language (Extensible Markup Language), has been developed. By using a SyncML synchronization protocol, which employs SyncML messages, data of any application can be synchronized between networked terminals of any kind.
FIG. 1 illustrates an example of synchronization where a mobile station MS acts as a SyncML client device and a network server S acts as a SyncML server. The SyncML synchronization service comprises first initializing a synchronization session (SyncML Session Initialization) during which, for example, the database to be synchronized is selected. A client agent MS sends the server S a SyncML message (Client Modifications) comprising at least the data which are to be synchronized in the mobile station MS and have changed since the last synchronization. The server S synchronizes the data sets, i.e. analyzes the changes made to the data sets and harmonizes the data (makes the necessary modifications, replacements, deletions and additions). After this, the server S sends the server modifications back to the client device TE, which makes the necessary changes to its database.
Other types of data can also be synchronized by means of the SyncML, whereby a new setting relating to synchronization, for instance, can be synchronized to the client device. Generally, device management refers to procedures, by which third parties can change the configuration of a device, e.g. change settings or even a protocol used by the device. Besides settings relating only to the device, it is also possible to send user-specific data, such as user profiles, logos, ringing tones and menus, by means of which the user can personalize the settings of the device or the adaptations are made automatically in the device management. Features which have been defined in the SyncML standard can be utilized in connection with the device management concept. A synchronization server can act as a device management server and a client device as a device to be managed (Device Management Client).
FIG. 2 illustrates device management (Client Management Session) according to a message of a synchronization protocol. In a session initialization message, a client device (MS) transmits to a synchronization server S, which performs device management, information on itself (same information as in the synchronization) to the server, in response to which the server transmits information of its own and device management commands (Server Management Operations). The client device responds by status information, after which the server may finish the session or transmit more device management commands. If the server transmits more management commands, the client device should respond to this by status information. After receiving status information, the server may always finish the session or continue it by transmitting more device management commands. The device management protocol can also function in such a manner that questions concerning what the user likes to update are first transmitted to the user, and the information on the user's choices is transmitted to the server. After this, the server may transmit the updates/operations required by the user in the next packet.
According to the SyncML protocol, a client device typically starts a synchronization session. However, particularly in the context of device management there are cases in which the server has the need to start the synchronization. For this case, the SyncML specification “SyncML Sync Protocol, version 1.0.1”, May 2001, chapter 8 (pages 49 to 50 ) describes a synchronization session initialization caused by a server (Server Alerted Sync): the server may send a (Sync Alert) request message, in which it requests the client device to start a SyncML session. After this, the client device starts the initialization of the SyncML session by transmitting a conventional (Client Initialization Package) packet. When the client device is a mobile station, problems arise due to the facts that the client device cannot be reached when the mobile station is switched off or that there is no continuous data transmission connection between the terminal and the server. This is why it is advantageous to use a service which stores the message when the request is transmitted. One of such services is SMS (Short Message Service), which stores a text message in a text message center and sends it when the mobile station is attached to the network and can be reached. Like other SyncML messages, a request for starting a session is in XML format and comprises a header field, which is determined in a [SyncHdr] element, and a body part, which is determined in a [SyncBody] element:
<SyncML><SyncHdr>. . .</SyncHdr><SyncBody>. . .</SyncBody></SyncML>
The request is relatively large and requires much greater capacity than 140 octets provided by the text message (which is sufficient for coding 160 ASCII characters of 7 bits). The request can be divided into several text messages, but it is possible that one of the text messages disappears, the messages arrive in wrong order or that the client device cannot process concatenated text messages. If a transport layer service is provided by WAP (Wireless Application Protocol), for instance, SyncML messages can be coded into binary WBXML format (Wireless Binary XML), and less data transmission capacity is required. Even though WBXML were used, the request still requires several text messages.